home *** CD-ROM | disk | FTP | other *** search
/ NetNews Offline 2 / NetNews Offline Volume 2.iso / news / comp / sys / amiga / programmer / 2559 < prev    next >
Encoding:
Internet Message Format  |  1996-08-05  |  3.7 KB
  1. Path: comma.rhein.de!serpens!not-for-mail
  2. From: mlelstv@serpens.rhein.de (Michael van Elst)
  3. Newsgroups: comp.sys.amiga.programmer
  4. Subject: Re: Amiga doesn`t need Planar!
  5. Date: 2 Feb 1996 00:43:43 +0100
  6. Organization: dis-
  7. Message-ID: <4erj7f$pb8@serpens.rhein.de>
  8. References: <john.hendrikx.4apt@grafix.xs4all.nl>
  9. NNTP-Posting-Host: serpens.rhein.de
  10.  
  11. john.hendrikx@grafix.xs4all.nl (John Hendrikx) writes:
  12.  
  13. >What if my object-mask looks like %01010101010101?
  14.  
  15. Then I'm much faster than chunky because I still hit memory by words.
  16.  
  17. >You can't tell if the mask
  18. >will be a constant 1, unless you hard-code this information with each object. 
  19.  
  20. Same amount of hardcoding necessary as for chunky.
  21.  
  22. >For a paint-program which can pick up a brush and paste it somewhere else it
  23. >has no way of knowing this, atleast not at an acceptable overhead.
  24.  
  25. Uh ? Sure it has.
  26.  
  27. >What about the amount of memory accesses?
  28.  
  29. As I said: memory bandwidth is about the same for objects that are large enough
  30. and smaller if you need less bits per pixel.
  31.  
  32. >Yes, this is pretty simple to implement as well at one extra memory access per
  33. >pixel.
  34.  
  35. Don't forget that this is a 100% increase.
  36.  
  37. >Planar could do it faster, but at a much higher price (it means losing
  38. >lots of colors).
  39.  
  40. It means to have the same amount of colors. Why should chunky suddenly have more
  41. bits ?
  42.  
  43. >spectacular effects.  In the end it will always be the CPU which delivers you
  44. >the newest effects.
  45.  
  46. And special hardware can deliver them cheaper. That's an old truth.
  47.  
  48. >Not just me, texturemapping is simply popular because it makes things look more
  49. >realistic and is within the range of our current processors.
  50.  
  51. You mean it is popular because PCs just have processors that are now fast enough.
  52.  
  53. >is no need to use low-bitplane Planar displays because even deep Chunky
  54. >displays are incredibly fast.  That kills one of the advantages of planar.
  55.  
  56. This is true.
  57.  
  58. >all, and it also causes a lot of the often used operations like plotting a
  59. >pixel (games)
  60.  
  61. Games rarely plot pixels.
  62.  
  63. >drawing a line (GUI's)
  64.  
  65. Mostly with 1bit per pixel.
  66.  
  67. >or blitting a masked-object (Games, paint
  68. >programs, gadget imagery, overlayed text, etcetera) to perform much slower.
  69.  
  70. Again something that a CPU is not good at.
  71.  
  72. >Yes it is, Chunky hardware performs the most popular operations much faster
  73. >than Planar hardware could.
  74.  
  75. It performs texture mapping faster.
  76.  
  77. >With the most popular operations I mean things
  78. >which are used for drawing a GUI and things now often seen in games.
  79.  
  80. But which is incorrect.
  81.  
  82. > MVE> Depends on the effects. You seem to focus just on effects that a
  83. > MVE> standard CPU can do.
  84.  
  85. >No, I focus on the usefull effects.
  86.  
  87. So useful effects are defined at what standard CPUs do ?
  88.  
  89. >Planar has much more severe alignment (and thus more overhead) problems and
  90. >needs to access memory (for a 16-bit object) at 16 different locations in
  91. >memory, while with Chunky this is all located in close vicinity of each other,
  92. >making optimisations like plotting LONGs instead of WORDs possible.
  93.  
  94. You mean the 128bit blitter is out ? It must have a 32bit bus ?
  95.  
  96. >Take an 8
  97. >pixel wide and 8 bit deep object,
  98.  
  99. I rather take a 80 pixel wide and 12bit deep object.
  100.  
  101. >one row could be plotted with Chunky in just
  102. >2 LONG writes.
  103.  
  104. Plus a gobble of checks wether the alignment rules are met.
  105.  
  106. >Yes, and we with our brilliant planar hardware are stuck with those hardware
  107. >limits as we can't upgrade our planar hardware without serious problems.
  108.  
  109. You mean that _chunky_ hardware wouldn't have had the same limitations ? If
  110. the Amiga had a chunky display then C= wouldn't have made bad decisions ?
  111.  
  112. This is starting to get a religious touch.
  113. -- 
  114.                                 Michael van Elst
  115.  
  116. Internet: mlelstv@serpens.rhein.de
  117.                                 "A potential Snark may lurk in every tree."
  118.